Hi KP

Am 26.09.2015 um 18:57 schrieb kp kirchdoerfer:
> Hi Erich;
> 
...
>> Why do you need to rebuild the packages? They should all be in the files
>> directory. 
> 
> To be shure the Packages, kernel etc are inline with the release.
> I didn't commit before I started to make updates.

If you published those in the files section they _must_ be identical to
the ones in the package repository. IMHO rebuilding is _wrong_, you
should use the ones already published.

> 
> As I tried to point before, requirements for upgrade doesn't fit well ino the 
> build process.  Most of the stuff could be done from the packages 
> directories, 
> but few files need to be collected from the builded images.
> This should be improved in the future - at least, once the upgrade process is 
> fixed. 

Once I have a target, that will not take long.

> 
>> I believe we need one single central repository for the
>> released packages and IMHO the package repository would be a fine place
>> to keep them.
> 
> Agree.
> 
>>> ...
>>>
...

>>
>> Well, my idea was (and will remain) to fork off whatever into a 5.2.0
>> branch and delete everything there which does not belong to 5.2.0, then
>> for 5.2.1 fork off 5.2.0 to just replace the specific files for 5.2.1
>> and so on.
> 
> Ok; definitely worth a try.
> 
>>> I doubt you can work with git tags.
>>
...

> 
> Hmm; I usually copy every builded package to packages/5_x; do you want me to 
> keep track of the changed Packages? This should be solved by git. And it is 
> when committing to a given repository.

Yes, but with the (current) schema used for upgrade it would not be good
to keep them in the same branch as the one used for upgrade as this
conflicts with the file layout.

I _believe_ we can branch off a tag, but I am really a noob when it
comes to git. So if this is true, we could tag a set of files
corresponding to 5.2.0 as T5.2 and branch off this tag.

http://stackoverflow.com/questions/10940981/git-how-to-create-a-new-branch-from-a-tag

So it looks like we can just tag master for a specific release and
branch off there once we are sure all the dependencies are resolved. I
then believe we should keep the major releases in a branch like so.

master -- T5.2 --- T5.3 --- T5.4
                    \
                      5.2.0 --- end
                             \
-- fixes for 5.2.0 ->    5.2.1 --- end
                                      \
-- fixes for 5.2.1 ->             5.2.2 --- end

This way we can keep packages for _every_ release without using lots of
space on sourceforge. If we are convinced a branch is poisonous we can
delete it without remorse and make the data disappear. The same goes for
EOL on the releases.

Maybe Yves can review this and give recommendations. All this can be
done with the standard git interface. I believe we should avoid having
to use add-ons.

cheers

ET


------------------------------------------------------------------------------

_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to