Bug #1615

Clean up bind commit to master, revert to vendor

Added by lentferj about 5 years ago. Updated over 4 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

the relevant branches can be found here:
http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/shortlog/refs/heads/bind_vendorupdate
http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/shortlog/refs/heads/vendor/BIND

there was some discussion on irc about where README.DRAGONFLY and
README.DELETED had to go.

I have left it the way I did it of vendor/LESS and as it was sugested on
irc (README.DRAGONFLY on master, README.DELETED on vendor).

But generally this should be clarified and the consensus should make
it's way into development(7).

Cheers,

Jan

History

#1 Updated by dillon about 5 years ago

:the relevant branches can be found here:
:http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/shortlog/refs/heads/bind_vendorupdate
:http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/shortlog/refs/heads/vendor/BIND
:
:there was some discussion on irc about where README.DRAGONFLY and
:README.DELETED had to go.
:
:I have left it the way I did it of vendor/LESS and as it was sugested on
:irc (README.DRAGONFLY on master, README.DELETED on vendor).
:
:But generally this should be clarified and the consensus should make
:it's way into development(7).
:
:Cheers,
:
:Jan

Cool. Simon (or someone), could you get that into the tree? I'm a
bit unsure how to do the vendor branch properly.

-Matt
Matthew Dillon
<>

#2 Updated by corecode about 5 years ago

[X-Post to kernel@ for discussion]

Jan Lentfer wrote:
> there was some discussion on irc about where README.DRAGONFLY and
> README.DELETED had to go.
>
> I have left it the way I did it of vendor/LESS and as it was sugested on
> irc (README.DRAGONFLY on master, README.DELETED on vendor).
>
> But generally this should be clarified and the consensus should make
> it's way into development(7).

Yes, we should decide. But both should be on the same branch, for
coherency.

Reasons for master:
- those files don't belong to the tar ball

Reasons for vendor branch:
- the READMEs describe the files (and what was removed) of the tar ball

I don't mind either, just coherency. I propose to decide on what goes
where first, and after that do the import. Or at least pack both files
into the same branch.

cheers
simon

#3 Updated by lentferj about 5 years ago

Zitat von "Simon 'corecode' Schubert (via DragonFly issue tracker)"
<>:

>
> Yes, we should decide. But both should be on the same branch, for
> coherency.
>
> Reasons for master:
> - those files don't belong to the tar ball
>
> Reasons for vendor branch:
> - the READMEs describe the files (and what was removed) of the tar ball
>
> I don't mind either, just coherency. I propose to decide on what goes
> where first, and after that do the import. Or at least pack both files
> into the same branch.

According to development(7) both should go on master:
"Now you are free to change the sources in contrib/foo, since you are back
on the master branch. The first thing to do is to add README.DRAGONFLY
and README.DELETED."

Just advises from irc where to split. So I wil stick to what is in
development(7) and put both on master.

Regards

Jan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

#4 Updated by corecode about 5 years ago

wrote:
> Zitat von "Simon 'corecode' Schubert (via DragonFly issue tracker)"
> <>:
>
>>
>> Yes, we should decide. But both should be on the same branch, for
>> coherency.
>>
>> Reasons for master:
>> - those files don't belong to the tar ball
>>
>> Reasons for vendor branch:
>> - the READMEs describe the files (and what was removed) of the tar ball
>>
>> I don't mind either, just coherency. I propose to decide on what goes
>> where first, and after that do the import. Or at least pack both files
>> into the same branch.
>
> According to development(7) both should go on master:
> "Now you are free to change the sources in contrib/foo, since you are back
> on the master branch. The first thing to do is to add README.DRAGONFLY
> and README.DELETED."

Well, that's what I wrote. However if people think that it is better to
put it on the vendor branch (and I can see reasons for that), then we
should change it.

cheers
simon

#5 Updated by lentferj about 5 years ago

Simon,

[...]
> I don't mind either, just coherency. I propose to decide on what goes
> where first, and after that do the import. Or at least pack both files
> into the same branch.

I put both files on master and also applied an update to bump to
version -P1 to fix a security issue. Please check the branches again
and consider commiting.

Regards

Jan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

#6 Updated by aoiko about 5 years ago

Simon 'corecode' Schubert wrote:
> [X-Post to kernel@ for discussion]
>
> Jan Lentfer wrote:
>> there was some discussion on irc about where README.DRAGONFLY and
>> README.DELETED had to go.
>>
>> I have left it the way I did it of vendor/LESS and as it was sugested
>> on irc (README.DRAGONFLY on master, README.DELETED on vendor).
>>
>> But generally this should be clarified and the consensus should make
>> it's way into development(7).
>
> Yes, we should decide. But both should be on the same branch, for
> coherency.

Agreed.

> Reasons for master:
> - those files don't belong to the tar ball

I think conceptually README.DELETED should be on the vendor branch --
after all we don't commit the tarball as is. We delete files first and
README.DELETED lists those deletions.

> Reasons for vendor branch:
> - the READMEs describe the files (and what was removed) of the tar ball

- Having README.DELETED on the vendor branch should make for a better
workflow:

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/e449f42a7c170b52bb09c6300ba5b6bfdc5a9a01

(Peter, any further input on this?)

> I don't mind either, just coherency. I propose to decide on what goes
> where first, and after that do the import. Or at least pack both files
> into the same branch.

Yah, it's no big deal but we should reach a conclusion and document the
procedure in development(7) ASAP, holding back Jan's changes because of
this is probably a bit frustrating for him.

FWIW, for the reasons above, I'd prefer keeping the READMEs on the
vendor branch.

Aggelos

#7 Updated by corecode about 5 years ago

Aggelos Economopoulos wrote:
> Simon 'corecode' Schubert wrote:
>> [X-Post to kernel@ for discussion]
>>
>> Jan Lentfer wrote:
>>> there was some discussion on irc about where README.DRAGONFLY and
>>> README.DELETED had to go.
>>>
>>> I have left it the way I did it of vendor/LESS and as it was sugested
>>> on irc (README.DRAGONFLY on master, README.DELETED on vendor).
>>>
>>> But generally this should be clarified and the consensus should make
>>> it's way into development(7).
>> Yes, we should decide. But both should be on the same branch, for
>> coherency.
>
> Agreed.
>
>> Reasons for master:
>> - those files don't belong to the tar ball
>
> I think conceptually README.DELETED should be on the vendor branch --
> after all we don't commit the tarball as is. We delete files first and
> README.DELETED lists those deletions.
>
>> Reasons for vendor branch:
>> - the READMEs describe the files (and what was removed) of the tar ball
>
> - Having README.DELETED on the vendor branch should make for a better
> workflow:
>
> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/e449f42a7c170b52bb09c6300ba5b6bfdc5a9a01
>
> (Peter, any further input on this?)
>
>> I don't mind either, just coherency. I propose to decide on what goes
>> where first, and after that do the import. Or at least pack both files
>> into the same branch.
>
> Yah, it's no big deal but we should reach a conclusion and document the
> procedure in development(7) ASAP, holding back Jan's changes because of
> this is probably a bit frustrating for him.
>
> FWIW, for the reasons above, I'd prefer keeping the READMEs on the
> vendor branch.

Alright, sounds good to me!

cheers
simon

#8 Updated by lentferj about 5 years ago

Simon 'corecode' Schubert schrieb:
> Aggelos Economopoulos wrote:
>> Simon 'corecode' Schubert wrote:

>> FWIW, for the reasons above, I'd prefer keeping the READMEs on the
>> vendor branch.
>
> Alright, sounds good to me!

Ok, could you check the branches again at

http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/shortlog/refs/heads/bind_vendorupdate
http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/shortlog/refs/heads/vendor/BIND

thanks

Jan

#9 Updated by dillon about 5 years ago

I'm wondering if we should even bother deleting anything any more
on the vendor branch, since the deletions could be done on the
master branch as a merge item.

-Matt
Matthew Dillon
<>

#10 Updated by corecode about 5 years ago

Matthew Dillon wrote:
> I'm wondering if we should even bother deleting anything any more
> on the vendor branch, since the deletions could be done on the
> master branch as a merge item.

Yes, I think we should, because we perform the deletes so that our repo
doesn't grow unnecessarily. A full gcc import will use much more space
(not in the checkout, but still in .git) than a cut down one. Also if
we delete files, we might as well do so in the vendor branch, which
allows for easier diffs to it (because all the deleted files don't show up).

cheers
simon

#11 Updated by lentferj about 5 years ago

Dear all,

after some conversation with Simon I have now come up with a submit that
will also remove the version tag from the bind directory.
Simon has checked it so far and thinks that it is ok, but he doesn't
have time to push it atm.

Maybe someone can jump in?

http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/shortlog/refs/heads/bind_vendor2
http://gitweb.dragonflybsd.org/~lentferj/dragonfly.git/shortlog/refs/heads/vendor/BIND

Jan

#12 Updated by pavalos about 5 years ago

On Sun, 29 Nov 2009 09:10:30 +0000, "Simon 'corecode' Schubert"
<> wrote:
> Matthew Dillon wrote:
>> I'm wondering if we should even bother deleting anything any more
>> on the vendor branch, since the deletions could be done on the
>> master branch as a merge item.
>
> Yes, I think we should, because we perform the deletes so that our repo
> doesn't grow unnecessarily. A full gcc import will use much more space
> (not in the checkout, but still in .git) than a cut down one. Also if
> we delete files, we might as well do so in the vendor branch, which
> allows for easier diffs to it (because all the deleted files don't show
> up).

I agree with Simon. We should not import the entire contents of the
extracted tarball.

Also available in: Atom PDF